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The  U.  S.  Army  currently  relies  on  raster  products  as 
source  data  for  map  background  displays  in  tactical  systems. 
In  the  future.  The  Defense  Mapping  Agency  would  prefer  to 
support  these  requirements  with  vector  products  to  reduce 
production  costs  and  take  better  advantage  of  their  new 
Digital  Production  System.  Creative  and  innovative  solu¬ 
tions  are  needed  to  allow  map-like  symbolized  displays  to  be 
generated  on  current  generation  con^uters,  within  acceptable 
time  tolerances,  using  vector  source  data.  Science  Applica¬ 
tions  International  Corporation  (SAIC)  luider  contract  with 
the  U.S.  Amy  Topographic  Engineering  Center  (TEC)  has 
demonstrated  that  this  can  be  done  effectively  using  special 
indexing  techniques. 


INTRODUCTION 

The  U.  S.  Army  currently  relies  on  rast  r  products  as 
source  data  for  map  background  displays  in  tactical  systems. 
Most  Amy  command  and  control  developers  utilize  Arc-Digi¬ 
tized  Raster  Graphics  (ADRG)  produced  by  the  Defense  Mapping 
Agency  (DMA) .  The  full  resolution  24-bit,  254  dpi  ADRG  is 
transformed  by  various  methods  to  produce  spatially  com¬ 
pressed,  reduced  color  variants.  Transformation  is  required 
due  to  the  limited  storage  and  display  capabilities  of  cur¬ 
rently  fielded  Amy  Common  Hardware  Systems.  For  example, 
the  file  size  of  one  1:50,000  Topographic  Line  Map  (TLM)  in 
full  resolution  ADRG  format  approaches  75  MB.  A  transformed 
4-bit,  127  dpi  TLM  requires  only  5  MB  of  storage. 

The  Amy  is  now  faced  with  the  prospect  of  changing  its 
source  data  for  map  background  displays  from  raster  data  to 
vector  data.  This  change  is  driven  by  DMA's  stated  desire 
to  cease  production  of  raster  products  in  the  long  term  and 
move  to  an  all-vector  product  line.  Citing  cost  concerns 
associated  with  the  production  of  raster  data  and  the  abili¬ 
ty  to  leverage  the  increased  production  capabilities  of  the 
Digital  Production  System  (DPS) ,  DMA  envisions  that  the 
majority  of  digital  products  released  in  the  future  will  be 
in  the  Vector  Product  Format  (VPF) .  The  move  to  VPF  data 


94  1  14  067 


sets  poses  a  host  of  technical  challenges  to  Anry  tactical 
systems  and  battlefield  weapons  developers. 

The  map  backgroiind  of  the  future  must  be  able  to 
perform  on  a  wide  range  of  con5>uter  platforms.  The  Army's 
current  thrust  towards  digitization  of  the  battlefield  will 
result  in  the  acquisition  of  thousands  of  new  systems.  The 
common  digital  map  background  required  by  this  diverse  array 
of  systems  is  intended  to  provide  situational  awareness  by 
displaying  a  quickly  recognizable  background  for  pinpointing 
friendly  force  locations  and  threats,  as  well  as  provide  the 
underlaying  attribution  required  to  support  mission  planning 
and  intelligence  analysis  activities.  While  many  of  these 
platforms  will  be  state-of-the-art  workstations,  much  of  the 
hardware  will  be  relatively  low  performace.  For  example, 
the  Lightweight  Computer  Unit  (LCU) ,  which  will  be  widely 
fielded,  is  a  468  CPU  running  SCO  UNIX  at  25  MHZ. 

Current  system  requirements  call  for  displays  to  be 
conpleted  in  a  matter  of  seconds.  While  existing  raster 
products  can  easily  meet  this  goal,  vector  products  experi¬ 
ence  significantly  increased  display  times  due  to  the  addi¬ 
tional  processing  demands  inherent  to  topologically  correct 
vector  data.  Creative  and  innovative  solutions  are  neces¬ 
sary  if  display  times  are  decrea.sed  to  the  point  of 
acceptability  by  Army  users.  Conpounding  the  problem  of 
rapid  display  is  symbology.  Displaying  conplex  area  fill 
patterns  or  cased  roads  can  rapidly  bog  down  a  low-end  Army 
tactical  system.  A  proper  balance  must  be  struck  between 
familiar  map-like  appearance  and  data  which  can  be  quickly 
displayed.  This  will  inevitably  require  some  re-education 
on  the  part  of  the  user,  however,  every  attempt  must  be  made 
to  approximate  a  map-like  appearance  whenever  possible. 

The  following  sections  discuss  work  performed  by  Sci¬ 
ence  Applications  International  Corporation  (SAIC)  under 
contract  with  the  U.  S.  Army  Topographic  Engineering  Center 
(TEC) .  Utilizing  several  indexing  schemes  on  a  "compacted" 
form  of  VPF  data,  SAIC  has  demonstrated  the  viability  of 
vector  data  as  source  for  map  background  displays  in  Army 
tactical  systems. 

XMDBXZNG  C0NCBPT8 

Rapid  map  displays,  based  upon  vector  data,  are  best 
supported  with  "dumb"  spaghetti  data  structures  that  have 
display  instructions  integral  with  point,  line,  and  area 
data  records.  DXF  is  an  example  of  this  data  structure  and 
it  is  so  compatible  with  many  mapping  systems  that  it  is 
becoming  a  defacto  exchange  standard  for  this  low  level 
vector  information.  However,  to  support  analysis,  such  as 
inputs  to  geographic  information  systems,  one  needs  "smart" 
data  which  is  another  way  of  saying  the  data  needs  to  in¬ 
clude  conprehensive  topology.  Topology  provides  information 


on  the  relationship  of  things  to  each  other.  For  exanple,  a 
road  can  be  related  to  the  areas  on  each  side  of  it  by  link¬ 
ages  established  with  topology.  Smart  data  carries  display 
overhead  due  to  the  built-in  topology  because  features  must 
be  traced  by  following  the  topological  relationships.  This 
paper  assumes  the  reader  is  familiar  with  these  concepts  and 
will  address  special  indexing  techniques  to  make  smasrt  data 
nearly  as  fast  to  display  as  dumb  vector  data. 

DMA's  Vector  Smart  Map  (VMAP)  program  is  soon  to  be 
producing  vector  data  with  full  topological  relationships, 
suitable  for  input  to  Geographical  Information  Systems 
(GIS) .  The  VMAP  data  conforms  rigorously  to  a  VPF  MIL-STD 
to  insure  interoperability  within  the  DOD  community.  Our 
work  has  explored  indexing  concepts  that  will  work  with 
DMA's  standard  data  structure,  as  well  as  other  data  struc¬ 
tures.  These  concepts  are  designed  to  optimize  display 
response  and  coir^ression  to  work  better  within  limited  hard 
disk  space  on  con^uter  platforms  used  with  the  U.  S.  Army's 
Common  Hardware  Software  (CHS)  program. 

There  are  two  general  classes  of  indices;  spatial  and 
thematic.  The  discussion  that  follows  treats  these  two 
classes  and  outlines  those  currently  defined  within  the  DMA 
Standard  as  well  as  special  ones  we  have  created  to  support 
the  Army's  requirements  for  speed  and  display  standardiza¬ 
tion. 

Spatial  indices  keep  track  of  records  that  have  a  high 
likelihood  of  existing  within  some  defined  spatial  region. 
Usually,  the  estimate  of  existence  is  based  upon  the  Minimum 
Bounding  Rectangle  (MBR)  intersecting  with  the  MBR  of  a 
prescribed  spatial  region.  It  is  not  critical  that  this 
estimate  is  precise,  as  long  as  every  spatial  record  is 
accounted  for  somewhere  in  the  spatial  index  and  the  appli¬ 
cation  software  properly  spans  the  index  structure. 

Spatial  indices  support  "What 's  That  *  queries  and  can 
also  be  used  to  delimit  spatial  records  that  exist  within 
some  display  window  of  interest.  The  work  done  in  this 
project  includes  a  magnification  zoom  option  that  is  partic¬ 
ularly  well  supported  by  spatial  indices.  In  general,  the 
smaller  the  spatial  region  of  interest,  the  more  rapid  the 
response  can  be  achieved  by  using  some  good  spatial  index. 
This  is  why  the  "What's  That"  query  is  usually  supported  by 
a  spatial  index.  Noimally,  this  query  seeks  the  closest 
feature  to  some  designated  point  on  the  screen,  which  is 
obviously  the  smallest  region  of  interest  definable. 

DMA's  VMAP  has  a  very  good  spatial  index  which  has  been 
compared  to  a  simple  grid  index  scheme  that  SAIC  has  used 
for  several  years  in  their  work  with  vector  data.  The  VMAP 


spatial  index  divides  the  overall  spatial  extent,  normally 
called  a  tile,  in  a  binary  sequence,  leaving  record  identi¬ 
fiers  in  the  undivided  region  whenever  they  cross  the  new 
dividing  line.  This  process  continues  until  some  predefined 
limit  for  division  is  reached,  or  no  further  assignment  of 
records  can  be  made.  Figure  1  illustrates  how  this  process 
works.  When  doing  a  "What's  that"  query,  the  point  of 
interest  defines  a  nested  set  of  cells,  all  of  which  must  be 
examined  for  candidates  for  being  closest  to  the  point  of 
interest  unless  the  query  is  restricted  to  point  features . 
When  delimiting  records  for  display  within  a  window  of  in¬ 
terest,  the  nested  set  of  cells  is  enlarged  to  include  the 
window.  This  enlarged  nest  of  cells  identifies  the  set  of 
records  that  might  have  elements  in  the  plot  window.  All 
records  identified  are  unique,  since  this  spatial  index  does 
not  contain  duplicate  record  ids  in  any  of  its  cells.  Each 
record  is  first  tested  against  its  MBR  for  potential  elimi¬ 
nation  and  the  survivors  are  then  displayed. 


Figure  1.  VPF  Spatial  Index  Showing  Cells  With  Feature 

Assignments 

The  Grid  Index  that  has  been  used  is  much  simpler  to 
describe,  develop,  and  use.  Basically,  the  tile  is  divided 
into  uniform  grid  cells  and  the  MBRs  of  all  records  are 
examined.  Any  record  that  has  an  intersection  of  its  MBR 
with  the  grid  cell,  becomes  a  member  of  that  grid.  When 
doing  a  "What's  That"  query,  the  point  of  interest  defines  a 


particular  grid  cell  and  the  records  within  that  cell  become 
the  candidates  for  being  the  closest  one  to  the  point.  When 
delimiting  records  for  display  within  a  window  of  interest, 
all  grid  cells  that  intersect  with  this  window  contain  re¬ 
cords  that  need  to  be  further  examined.  The  same  feature 
may  be  spatially  identified  by  more  than  one  cell  so  the 
unique  set  of  identified  features  must  first  be  determined. 
Next,  the  actual  intersection  of  feature  MBRs  and  the  window 
of  interest  are  tested.  Finally,  the  set  of  features  that 
qualify  for  display  are  actually  plotted.  Figure  2  illus¬ 
trates  the  grid  index  concept. 

While  the  two  spatial  index  schemes  described  above  are 
quite  different  in  their  development  and  use,  we  found  very 
little  difference  in  the  display  response  time  when  we  test¬ 
ed  them  using  VMAP  prototype  data  sets.  Both  can  be  adapted 
to  specific  data  sets  by  recognizing  how  they  react  to  spa¬ 
tial  characteristics.  Large  data  sets  of  points  could  be 
queried  faster  if  the  spatial  index  is  forced  to  high  reso¬ 
lution  delineation  (i.e.  more  grid  cells  or  finer  division 
of  spaces) .  On  the  other  hand,  data  sets  with  large  areas 
may  work  better  with  low  resolution  spatial  indices . 

Since  we  found  no  particular  advantage  in  using  the 
grid  index  over  the  defined  VMAP  index,  we  plan  to  use  the 
VMAP  Standard  for  the  Army  Standard  Map  Background  work. 
However,  there  may  be  other  applications  which  the  grid 
index  offers  a  speed  advantage.  Moving  map  displays  are  one 
such  exan^le. 

Moving  map  displays  are  inqportant  for  map  displays  in 
moving  platforms  (airplanes,  ships,  tanks,  etc.).  Raster 
maps  are  relatively  easy  to  handle  in  these  applications 
since  the  display  can  be  "fringe"  loaded.  Fringe  loading 
sinply  adds  new  rows  (or  columns)  of  data  as  the  platform 
moves  relative  to  the  map  reference.  When  using  vector  data 
to  support  moving  map  displays,  the  fringe  loading  idea 
needs  to  be  supported  with  a  spatial  index.  The  grid  index, 
noted  above,  is  directly  applicable  since  the  row  (or  col¬ 
umn)  of  grid  cells  identifies  precisely  the  right  new  fea¬ 
tures  that  must  be  interrogated  for  generating  the  new 
fringe  areas  that  must  be  displayed. 


Figure  2.  SAIC  Spatial  Index  Showing  Features  With  Grid 

Assignments 

Thematic  Indices 

Thematic  indices  basically  keep  track  of  things  you 
want  to  see  in  the  map  display  and  allow  software  to  effi¬ 
ciently  locate  the  proper  records.  In  addition,  there  is  a 
spatial  element  to  thematic  indices  when  tiles  are  used  to 
divide  the  data  into  convenient  subsets.  In  this  case, 
things  you  want  to  see,  are  identified  within  the  tile 
structure.  Highly  attributed  data,  typical  of  high  resolu¬ 
tion  emd/or  terrain  analysis  data,  offer  a  very  diverse  set 
of  options  for  data  display.  For  these  reasons,  design  of 
thematic  indices  can  be  fairly  complex  and  challenging. 

DMA's  VMAP  Prototypes  have  illustrated  several  options  for 
thematic  indices  and  the  VPF  MIL-STD  has  defined  the  generic 
structure  for  many  others.  The  most  general  definition  of  a 
thematic  index  is  eui  Inverted  List.  By  sorting  an  Inverted 
List  it  is  possible  to  use  a  Binary  Search  to  find  specific 
subsets  of  items  in  a  column  of  information.  Boolean  alge¬ 
bra  cem  also  be  applied  to  coliamns  of  information  to  identi¬ 
fy  combinations  of  attribute  information  to  support  specific 
objectives.  In  essence,  this  is  what  we  have  done  to  sup¬ 
port  the  Amy's  goal  of  rapid  display  of  standardized  map 
backgrounds.  We  have  formalized  these  procedures  to  allow 
most  of  the  conputer  processing  to  be  done  during  index 
preparation,  thus  allowing  the  display  software  to  sinply 


use  the  result  to  get  spatial  records  and  properly  display 
them.  The  paragraphs  that  follow  anplify  how  this  is  done. 


VMAP  data  bases  consist  of  libraries  which  have  layers 
of  data  called  coverages.  Coverages  consist  of  feature 
information  (feature  codes  and  attributes)  linked  to  spatial 
primitives.  Usually  the  spatial  primitives  are  stored  in 
tiles  which  cover  the  spatial  extent  of  the  library.  Fea¬ 
ture  information  is  stored  in  feature  tables  and  each  row  of 
the  feature  table  links  the  feature  to  its  spatial  primitive 
with  a  tile  and  spatial  element  id  number.  If  a  feature 
requires  more  than  one  spatial  element  to  describe  its  spa¬ 
tial  extent  then  the  linkage  occurs  through  join  tables. 
Since  map  displays  are  spatially  defined,  the  first  order 
thematic  index  must  be  a  tile  index.  So  far,  all  VMAP  pro¬ 
totypes  have  included  a  tile  index  and  one  would  expect  this 
to  continue  into  the  production  phase  since  this  is  always 
required  for  efficient  retrieval  of  display  information. 

VMAP  uses  the  Feature  and  Attribute  Coding  Catalog 
(FACC)  to  describe  features.  This  system  consists  of  a  5- 
character  feature  code,  using  the  first  one  or  two  charac¬ 
ters  to  describing  a  basic  hierarchy  of  information  layers 
such  as  drainage,  elevation,  population,  transportation, 
etc.  The  remaining  characters  are  used  to  extend  the  hier¬ 
archy  to  the  extent  needed  with  these  basic  layers.  Each 
feature  code  (FACC)  may  have  one  or  more  attribute  codes. 
These  attributes  carry  actual  measured  values,  like  length, 
width,  area,  etc.  or  a  coded  value.  Coded  values  have  mean¬ 
ing  described  in  a  specification  based  table.  Thus,  a  road 
feature  (FACC=AP030)  has  several  attributes: 


ACC ... accuracy  category  NAM. 
EXS. . .existence  category  RST. 
LCX:. .  .location  category  RTT. 
LTN. . .number  of  lanes  USE. 
MED. .median  category  NDl. 


WTC. . .weather  type  category 


.name 

.surface  type 
. intended  use 
. usage 

.width  of  traveled  way 


10 . .  .unknown  1 . .  .hard/paved  2. . .  loose/unpaved 
3 . . .loose/ light 

All  values  are  coded  except  LIN,  NAM,  and  WDl  which  are 
actual  values.  For  example,  the  coded  values  assignable  to 
RST  are: 


For  RTT  the  assignable  values  are: 


with  this  brief  overview  of  VMAP  constructs,  we  can 
describe  our  TSsematlc  Library  Concept.  This  concept  defines 
feature  identification  by  tile  and  includes  symbology  codes. 
In  other  words,  it  identifies  map  background  features  you 
may  want  to  display  and  includes  the  color  and  style  used  in 
the  display.  The  identified  features  may  only  require  a 
particular  FACC  or  they  may  require  multiple  FACCs  and/or 
several  selected  attributes  and  coded  values.  Development 
of  the  Thematic  Library  is  a  deliberate  tailoring  of  select¬ 
able  feature  sets  and  is  highly  dependent  on  data  content  in 
order  to  satisfy  the  end  user. 

Thematic  Library  entries  include  identification  of  data 
library,  coverage,  class  (Point,  Line,  Area,  Text),  symbolo¬ 
gy  codes,  number  of  features,  and  a  pointer.  The  pointer 
identifies  the  entry  location  in  a  companion  file  that 
stores  the  spatial  element  ids  that  belong  to  the  feature. 

An  example  of  a  portion  of  a  Thematic  Library  for  road 
features  is  shown  below. 


Id 

Lib 

Theme 

Class 

color 

Style 

1  num. 

ptr 

definition 

1. 

1 

trans 

line 

0 

37 

20 

1 

EXS=5 . . .under 
construction 

2. 

1 

trans 

line 

2 

2 

107 

21 

RTT=15 . . . 
limited  access 

3. 

1 

treuis 

line 

1 

1 

432 

128 

RTT=13 . . . 
primary  route 

4. 

1 

trans 

line 

3 

0 

1194 

560 

RTTsl4  &  RSTsl  & 
WTCol  secondary 
route,  paved,  all 
weather 

5. 

1 

trans 

line 

0 

13 

3929 

1754 

RTTb14  6  RSTs2  & 
WTCa2  secondary 
route,  paved,  all 
weather 

Similar  thematic  library  entries  are  made  for  other  coverag¬ 
es  of  VMAP  as  well  as  terrain  analysis  features  from  another 
DMA  libra:^  called  Interim  Terrain  Data  (ZTD).  An  exair^le 
of  a  portion  of  the  Thematic  Index  Library  made  from  ITD  is; 


FACCbSA.050  (s1op«  polygozis)  for  all  that  follow 


Id 

Lib 

Theme 

Class 

color 

Style  num. 
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where  gsc  stands  for  ground  sl^e  category 

The  Library  code  (3)  is  arbitrarily  assigned  and  must  be 
handled  by  the  application  software  in  the  current  state  of 
development.  More  sophisticated  use  of  VMAP  files  could 
make  this  a  table  driven  element. 

Once  the  Thematic  Index  Libraries  have  been  developed, 
it  is  straight  forward  and  easy  to  select  specific  theme 
indices  for  specialized  applications.  In  particular,  we 
were  tasked  to  define  features  for  displays  at  various  lev¬ 
els  of  zoom  (relative  to  map  scale  resolution) .  When 
zoomed-out,  the  feature  content  should  be  reduced  to  give  a 
general  orientation  of  the  area.  The  reduced  resolution 
reduces  clutter,  and  most  importantly,  decreases  rendering 
time.  When  zoomed-in,  the  feature  content  should  be  the 
most  detailed  based  on  the  tailoring  used  in  making  the 
Thematic  Index  Library.  Symbolization  should  also  be  the 
most  comprehensive,  using  meaningful  symbols  for  point  fea¬ 
tures  and  area  fill  patterns.  Displays  at  or  near  scale, 
i.e.  having  spatial  extents  similar  to  the  source  graphic, 
should  fall  between  the  extremes  described  here.  The 
symbolization,  for  exanqple,  can  be  simplified,  again  to 
reduce  clutter  and  speed  display  time. 

To  date,  we  have  defined  nine  specialized  thematic 
indices;  three  levels  of  zoom  for  each  of  three  general 
categories  of  map  background.  The  three  background  catego¬ 
ries  are: 

(1)  General  Map  Background,  (2)  Slope-Emphasized  Map  Back¬ 
ground,  and  (3)  Surface  Material-Emphasized  Map  Background. 


results 


The  best  way  to  describe  results  obtained  so  far  would 
be  to  demonstrate  the  Standard  Map  Background  Displays. 

This  will,  in  fact  be  happening  within  the  Anny  Community  in 
the  near  future.  Central  to  this  demonstration  is  the  ap¬ 
plication  software  being  used  and  the  computer  platforms 
being  used  to  host  this  software.  The  software  has  evolved 
over  a  period  of  three  years  supporting  a  multitude  of  ap¬ 
plications  using  raster  and  vector  data  bases.  Many  index¬ 
ing  concepts  have  been  used  and  a  compressed  form  of  DMA's 
vector  products  has  proven  to  be  particularly  useful.  In 
this  section,  we  will  discuss  the  software,  mention  a  few 
characteristics  about  the  compressed  data  structure,  and 
highlight  the  performance  obtained  with  the  various  indices. 

The  Geographic  Display  and  Query  System  (QDAQS) 

The  Geographic  Display  and  Query  System  (GDAQS)  was 
developed  on  a  SUN  UNIX  platform.  It  is  written  in  the  “C“ 
language  and  uses  MOTIF.  It  has  been  successfully  ported  to 
HP  9000  and  Silicon  Graphics  platforms.  Some  of  the  modules 
were  developed  under  a  SAIC  sponsored  IR&D  program,  so  they 
have  been  identified  as  conpany  proprietary.  In  general, 
the  code  should  be  considered  "engineering  code*  which  works 
well  but  has  not  undergone  rigorous  design  development  and 
documentation.  It  is  not  "frozen"  and  tends  to  take  on  new 
capabilities  almost  daily.  In  addition  to  demonstrating  the 
indices,  the  code  supports  many  data  browse  features  and  is 
useful  for  rapidly  inspecting  data  content.  SAIC  has  fur¬ 
nished  the  Executable  Programs  to  TEC  for  use  in  refining 
the  indices  that  will  support  Standard  Amy  Map  Background 
Displays.  Negotiations  are  now  underway  to  deliver  a  fully 
doc\amented  version  of  the  source  code. 

Compreased  Data  Structure 

Early  in  the  development  of  the  Vector  Product  Standard 
(circa  1990),  it  was  noted  that  a  compressed  form  of  the 
data  would  be  useful.  This  was,  in  fact,  noted  as  an  objec¬ 
tive  in  a  major  DMA  stu(^  aimed  at  moving  fully  into  the 
digital  products  arena.  Suggestior i  on  how  this  could  be 
done  have  been  noted  with  interest  by  many,  rejected  by 
some,  and  will  probably  be  reinvented  by  others  some  time  in 
the  future.  SAIC  is  willing  to  share  their  ideas  with 
anyone  interested  and  would  take  pride  in  having  DMA  use 
them  in  future  refinements  to  the  VPF  MIL-STD. 

Reduced  storage  volume  is  achieved  by  using  2 -byte 
integers  for  each  coordinate  element  as  an  offset  from  the 
tile  lower  left  corner  reference.  Since  the  VPF  Standard 
prescribes  4-byte  point  for  coordinates  so  the  2-byte  offset 
gives  a  2:1  advantage  with  essentially  no  loss  in  accuracy 
for  tile  sizes  currently  defined  for  VMAP  products.  Unpack- 


ing  the  2 -byte  data  does  add  some  processing  overhead,  but 
timing  runs  have  shown  this  time  penalty  to  be  small...  on 
the  order  of  1  percent  of  the  total  display  time.  Other 
data  structure  constructs  include  consolidation  of  files  and 
use  of  2-l:yte  integers  instead  of  4 -byte  integers  wherever 
possible.  Overall  storage  volume  turns  out  to  a  little  less 
than  half  the  original  volume  and  the  number  of  files  about 
one  third  the  original . 

Response  Time  of  Standard  Index  Driven  Mao  Backaromid  Dis¬ 
plays 


There  are  obviously  many  variables  associated  with  map 
background  display  times.  The  main  ones  are;  computer  plat¬ 
form,  degree  of  zoom,  data  density,  complexity  of  symboliza¬ 
tion,  and  indexing.  Our  goal  has  been  to  support  display 
times  that  are  on  the  order  of  3 -to  5-seconds  on  a  low  end 
Sun  SPARC  (IPC)  platform.  We  believe  this  platform  is  on  a 
par  with  a  486/33  PC  as  far  as  speed  performance.  The  most 
dense  data  set  available  is  the  Fort  Hood  (Killeen)  area 
which  is  probably  no  more  than  moderate  density  when  judged 
on  a  world  wide  scale.  The  control  of  display  times  is 
through  selection  of  individual  indices  from  the  Index  Li¬ 
brary.  The  Index  Library  includes  symbology  assignments,  so 
it  is  possible  to  repeat  features  in  the  library  using  dif¬ 
ferent  symbology  assignments . 

Display  times  are  considered  optimal,  i.e.  the  best 
that  can  be  done,  while  maintaining  all  of  the  “smart"  or 
analytic  power  within  the  VMAP  data.  Simpler  point  symbols 
could  be  important  for  data  with  numerous  complex  features 
(windmills,  mines,  etc.)  but  for  the  samples  at  hand  this 
has  not  been  a  major  consideration. 

We  feel  the  performance  achieved  is  quite  good  and 
hosting  the  software  on  higher  performance  platforms  will 
almost  eliminate  concern  with  display  times.  Higher  perfor¬ 
mance  platforms  are  a  natural  evolution  in  the  computer 
industry  but  the  performance  in  hand  now  seems  adequate  to 
satisfy  field  users  that  want  to  use  smart  vector  data  for 
map  backgrounds.  The  indexing  concepts  come  very  close  to 
performance  achievable  with  low  level  (dumb)  vector  data  and 
the  same  data  carries  analytic  power  needed  for  GIS  func¬ 
tions  . 


SDMUARY 

An  indexing  concept  has  been  developed  that  supports 
the  needs  of  Amy  system  users  for  rapid  map  background 
display  using  current  generation  conputers.  Tailored  indi¬ 
ces  are  defined  based  on  DMA's  Vector  Smart  Map  contents  as 
well  as  terrain  analysis  features  contained  within  DMA's 
Interim  Terrain  Data  products.  Indices  include  symbology 


codes  which  may  vary  in  con^lexity  as  a  function  of  degree 
of  zoom  for  which  the  index  is  designed  to  support. 

So  far,  three  choices  of  map  background  display  have 
been  defined  with  supporting  indices: 

"'^^T^™"5enera!nfa^Bac!cgrounc^^^^s?T^^^Iat"'^Top?"""" 

graphic  line  map  presents 

2)  Slope  and  contour  emphasis. . .slope  polygons, 

color  coded  by  degree  of 
slope  with  selective 
contour  lines  overlaid 
and  some  map  features 
(roads,  streams,  built-up 
areas,  etc.) 

3)  Surface  material  and  contours ...  surf ace  material 

polygons,  color  coded  hy 
type  of  material  with 
overlays  similar  to  2) 


1) 

Zoomed-out 

(from  map  scale) 

2) 

At  or  near 

scale 

3) 

Zoomed- in 

For  each  map  background,  noted  above,  indices  define  feature 
and  symbology  content  for  three  levels  of  zoom: 


where  scale  is  defined  as  the  equivalent  feature  spacing 
seen  on  the  1:50,000  source  graphic. 

Display  times  are  on  the  order  of  3-to  5-seconds  on  a 
low  end  SUN  (IPC)  platform.  A  magnification  feature  allows 
small  displays  (3"  by  3")  to  be  very  quickly  generated  (1-to 
2 -seconds)  and  these  allow  map  subsets  to  be  viewed  at 
larger  scale.  The  increased  scale  is  currently  set  for  a 
factor  of  three  magnification,  and  the  small  displays  occur 
without  disturbing  the  base  display.  These  subset  displays 
can  be  dragged  to  convenient  locations  on  the  screen  and 
others  can  be  generated  as  desired. 

The  overall  goal  of  creating  standard  map  background 
displays  has  been  achieved.  The  indexing  concepts  work  with 
DMA's  products  without  translation,  or  with  a  compressed 
form  of  the  data.  The  adaptive  symbology  assignments  along 


with  the  basic  indexing  concept  allow  vector  smart  data  to 
be  used  in  both  analytic  GIS  environments  and  simpler  map 
background  applications. 


